1. Field of the Invention
The present invention relates to a program compile system and its compile method for compiling a source program described in a programming language to an object program described in a processor executable language (machine language, assembly language, etc.).
2. Description of the Related Art
As the conventional program compile system, there is a system disclosed in, for example, Japanese Patent Publication Laid Open (Kokai) No. Heisei 1-118931, "Program Conversion Method". FIG. 15 is a block diagram showing the electrical structure of the conventional program compile system disclosed in the same publication.
The conventional program compile system shown in FIG. 15 comprises a first program storing unit 210, a compiler 220, a second program storing unit 230, a third program storing unit 240, an input data storing unit 250, a program executing unit 260, a fourth program storing unit 270, and an analysis result storing unit 280.
In the program compile system, the compiler 220 reads a source program from the first program storing unit 210, generates a temporary object program in which a procedure, function, subroutine (hereinafter, they are generically referred to as "procedure") have not been optimized, and stores the program into the second program storing unit 230. FIG. 16(a) shows an example of a source program described in the C language, that is one kind of programming language.
Next, the program executing unit 260 reads a program for analyzing the procedure calling frequency from the fourth program storing unit 270, and executes the program. Namely, the program executing unit 260 reads the temporary object program from the second program storing unit 230 and reads necessary input data from the input data storing unit 250. Simulating the execution of the temporary object program, the unit 260 adds up the number of times a procedure is called, in every procedure within the temporary object program. Each resultant summation is stored in the analysis result storing unit 280 together with the code amount (code size) of the corresponding procedure, as the procedure calling frequency analysis result.
Reading the analysis result of the procedure calling frequency from the analysis result storing unit 280, the compiler 220 judges whether the frequency of each procedure being called is beyond the predetermined standard and whether the size of each procedure is beyond the predetermined standard. Whether the optimization of each procedure should be performed or not by inline expansion, depends on the judgement result; if it is necessary, the optimization by the inline expansion is performed. Here, the optimization by the inline expansion means that a call code of a procedure on a source program is converted into execution code string for directly processing the procedure in an object program. Performance of the optimum inline expansion can eliminate the overhead caused by stack frame generation and register saving at the calling time of a procedure, thereby improving the running speed when a computer runs an object program.
As mentioned above, the compiler 220 generates a final object program and stores the program into the third program storing unit 240. FIG. 16(b) is an example of the final object program expressed in the C language, which the source program shown in FIG. 16(a) has been compiled to and the optimization processing by the inline expansion has been performed on.
In these days, prevailing is a programming language, which is based on such a thinking that a system is tried to be expressed by the group of an integrated object with the data group and the procedure group for using the data. This thinking is called as an object oriented one, and the programming language based on this object oriented thinking is called as an object oriented language. There is the Smalltalk as the typical object oriented language. Further, there appear many programming languages, such as C++, TURBO PASCAL, in which the object oriented thinking is added to the existing programming languages of the procedure announcement type.
In these object oriented languages, there is a tendency to increase not only use of a direct call of a procedure but also use of an indirect call thereof, for processing's sake. In order to generate such an efficient object program that can be run faster by a computer, it is necessary to perform some optimization on an indirect call. Here, a direct call means such a call that, as illustrated in FIG. 16(a), a call code for a procedure is described at a position on the source program and that the relevant procedure is directly called at the position. An indirect call means such a call that, as illustrated in FIG. 17, an address of a procedure is assigned to a specified variable (pointer: variable "fp" in the case of FIG. 17) at a position on the source program and that the relevant procedure is indirectly called by use of the variable at the other position (at the 300th line, in the case of FIG. 17).
The optimization processing by inline expansion in the above mentioned conventional program compile system, however, cannot be adopted to an indirect call procedure, but only to a direct call procedure. This is why, for example, in the source program shown in FIG. 17, when the expression is satisfied under the branch conditions shown at the first line to the sixth line, the address of the procedure "g" is assigned to the variable "fp"; while, when the expression is not satisfied, the address of the procedure "h" is assigned to the variable "fp", and at the same time, at the 300th line, a procedure is indirectly called by the variable "fp"; however, it is impossible to decide whether the procedure actually called at the 300th line is the procedure "g" or the procedure "h" when the compiler 220 compiles the source program to a temporary object program.
When these codes are described in lines closer to each other, it is possible to decide whether the procedure called by an indirect procedure call is either the procedure "g" or the procedure "h" in the static analysis with no execution of a temporary object program; however, an indirect call code for a procedure is at the 300th line, far from the address assignment code toward the variable "fp" of either the procedure "g" or "h", in FIG. 17. This is intended to show that the static analysis is impossible in the case of FIG. 17.
Therefore, the above-mentioned conventional program compile system is defective in that a source program including an indirect procedure call cannot be compiled to an efficient object program.